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. TECHNICAL FIELD . 
This invention relates to the connection of devices in automated transaction machines. 
Specifically this invention relates to a new method and system for connecting transaction 
services in automated transaction machines. 

BACKGROUND ART 

Automated transaction machines are known in the prior art. Automated transaction 
machines are used to electronically carry out transfers representative of value. Automated 
transaction machines include for example, cash dispensers, ticket dispensers, scrip dispensers, 
gaming machines, Automated Teller Machines (ATMs) and other self service terminals. For 
purposes of convenience all such automated transaction machines will be referred to herein as 
ATMs unless otherwise specifically indicated. 

ATMs may include various types of transaction function devices. These devices are 
operated to carry out transactions. Different types of ATMs include different types of devices. 
The different types of devices enable the ATM to carry out different types of transactions. For 
example, some types of ATMs include a depository for accepting deposits while other ATMs do 
not. Some ATMs have a "touch screen" while others have separate displays and input buttons. 
ATMs can also be fitted with devices such as cash and coin acceptors, statement printers, check 
validators, bill acceptors, thumb print readers and other types of devices, while other ATMs do 
not include such devices. ATMs also continue to incorporate improved or additional features. 
For example, printers are improved from black to color inks; cash acceptors are improved to 



work with both old and new styles of a twenty-dollar bill; and card readers are improved so they 
can work with magnetic stripe cards and smart cards. 

As long as the basic functionality of a new device is the same as a device it replaces, the 
software code or drivers needed to communicate with the new device may also remain generally 
the same. Thus for example the application software for an ATM with a cash dispenser can issue 
a command to dispense cash as it has always done even after the cash dispenser is improved. 

However, if the new device is so substantially changed relative to a device that it replaces 
so that it requires an updated driver, a service technician will be required to install a new device 
driver with the new device. As long as the new driver is backward compatible with the older 
driver, the ATM will continue to function generally as before. 

Unfortunately installing new drivers can require more time than installing a new physical 
transaction function device in the ATM. Normally new drivers are installed from a floppy disk, 
CD ROM or other portable storage medium. A technician is required to access the computer that 
runs the ATM, and must replace the physical files of the old drivers with the new drivers. Even 
when user friendly setup programs or wizards are used to make this process easier, it requires a 
degree of specialized knowledge and expertise to update the ATM software driver correctly. 

For example, a single type of device may have a different driver for each model and 
version that has been manufactured. Keeping track of the correct drivers and verifying that the 
correct driver is installed for a device, is a tedious endeavor. Furthermore it may not be obvious 
when a driver for "Model A" of a device is incorrectly used for "Model B". Although 99% of the 
functionality of the device may work properly, an ATM with an incorrect driver may experience 
intermittent problems related to that 1% of incompatibility with the driver. 



Tracking down these incompatibilities can consume a large amount of a technician's 
time. Consequently it would be desirable to streamline the updating of drivers to reduce the 
amount of time it takes to update a device and to reduce the chances of installing the incorrect 
driver for a new device. 

A typical ATM application program not only communicates through an interactive user 
interface with input and output devices, but also controls the overall functionality of the devices 
in an ATM. Prior art ATMs generally require that the ATM be shut down when a new or 
additional device is installed. Prior art systems assume that individual devices that are 
configured for use in the ATM will remain available while the ATM is operating. However, if a 
device is disabled, prior art ATMs may not notice that the device is disabled until the ATM 
attempts to use the device, at which time an error is generated. Such an error usually results in 
the entire ATM or system being disabled until the device is reenabled or the ATM is manually 
reconfigured to know that the device is no longer available. 

Consequently, changes to the configuration of an ATM require disabling the ATM for a 
period of time to remove, replace or add a device. This process can be time consuming and may 
result in lost business at the ATM. Consequently it would be desirable for an ATM to have the 
ability to detect when devices are present or not present and to automatically change 
configuration while continuing to "operate. 

Often functions of a device in an ATM are directly controlled responsive to inputs to a 
user interface. Individual devices often do not control the functionality of other devices. For 
example, when an ATM application program needs to lock or unlock a device which contains 
envelopes and also needs to enable a device which accepts deposit envelopes, the application 
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must issue commands to both devices. This is the case even though both devices are related and 
are designed to operate at proximate times. Individual ATM transaction devices often do not 
communicate with each other. For example, a device for receiving deposit envelopes does not 
issue a command to the envelope holder to close the door to the holder when the deposit function 
is completed. The application program must generally include all the programing logic for 
coordinating the operation of multiple devices. The additional code required makes the 
application program more complex and more difficult to modify. Consequently it would be 
desirable for ATM devices to communicate directly with each other to facilitate the performance 
of coordinated activities by transaction function devices. 

Prior art device drivers for devices in an ATM are often composed of low level functions 
for controlling the hardware. Programmers who create ATM software are generally required to 
have a high degree of knowledge about how a hardware device and device drivers are designed to 
work before the device can be incorporated into an ATM. This low level complexity often 
makes ATM application programs more complex and difficult to produce and reconfigure. 
Consequently it would be desirable to increase the efficiency of programmers who develop ATM 
software and to make device drivers easier for programmers to integrate into an ATM program 
without requiring the programmer to have an in-depth understanding of the low level hardware. 

Many types of ATMs include an internal device bus to which transaction devices are 
attached. This device bus facilitates the communication between the application program and the 
individual devices. Such device buses are often proprietary and are designed to connect directly 
with the computer that controls the operation of the ATM. Such device buses limit the number 
of devices that can be attached to an ATM and limit the physical locations at which devices can 



be attached. Consequently, it would be desirable to have an ATM with a system for attaching 
devices that is not limited to the physical constraints of an internal bus. 
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DISCLOSURE OF INVENTION 
object of the present invention to provide an. ATM in which transaction devices 



5 may be more easilys^onnected. 

of the present invention to provide an ATM in which the amount of time it 




takes to add a transaction function 



It is 



ATM is reduced. 

ect of the present invention to provide an ATM in which the possibility 



of installing a wrong driver for jTctevijje in the ATM is reduced. 
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\a install device drivers ii 



is 



rther object of the present invention to provide an ATM in which it is easier to 
ATM. 

her object of the present invention to provide an ATM in which device drivers 
are easier to incorporate^into ATM programs. 

ect of the present invention to provide an ATM in which transaction 
15 devices have properties of object orfeated services in the ATM. 

& . 

is a^ftuiher object of the present invention to provide an ATM which includes services 



Q 
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that encapsulate the lowlfev^l hardware functionality of a device and present only high level 
object oriented methods and events f&is^ontrolling the device. 
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is a fifcttier object of the present- invention to provide an ATM which includes an 
application program antJsQther software components in the ATM which include properties of an 
object oriented service. 

^further object of the present invention to provide an ATM which includes a 
5 transaction service wfejch operates to automatically install its own drivers when the service is 
installed in the ATM 

It llh&Jurther object of the present invention to provide an ATM in which services directly 
communicate with otlte^services in the ATM. 

It is aTf^ther object offhes^resent invention to provide an ATM in which services control 
the functionality of other N se£vices in the ATM. 

It isa^fttttijer object of the present invention to provide an ATM in which services may be 
dynamically added and removecN*itiiout disabling the entire ATM. 

irther object of the present invention to provide an ATM in which many services 




; : are attached, 



be attached to the ATM at a great dist 



It is 



ler 



of the present invention to provide an ATM in which a service may 
the main housing of the ATM. 
object of the present invention to provide an ATM in which services are 



connected to the ATMfflpQjigh a network. 

huSohf-? .... 

* s It is a furtR5r«tuect of the present invention to provide an ATM m which services are 

20 connected to the ATM with differenTtypes^f network topographies and protocols. 
^1^\0 ^^/^ is^a furthei^ob^ present invention to provide an ATM in which services issue 

events remotely across a netwo?fc<^hen there is a change in the state of the service in the ATM. 



is afiiriiier object of the present invention to provide an ATM in which services invoke 



method calls remotely acros§ > asCietwork to control other services in the ATM. 




her object of the present invention to provide an ATM which uses a service 



unicate with another service in the ATM. 



proxy to enable a service 

/ iTis allrrthCT object of the present invention to provide an ATM which passes service 



proxies across a network bettveeT^d^^Jerent services and programs in the ATM. 

is a ftother object of the present invention to provide an ATM which operates to store 



service proxies in a cenfrahsqpository located on a network in the ATM. 
llK look up a required sfei^ice proxy by querying the central repository of proxies on the network in 



^further object of the present invention to provide an ATM in which services can 



the ATM. 
(I* 



It is a 



■ object of the present invention to provide an ATM server that can 



coordinate the ftmctionalitjTo?>^Jurality of networked ATM workstation services. 

^ TA : - " — * of the presenflnvention to provide an ATM that can quickly connect 




15j and disconnect with services 




object of the present invention to provide an ATM that can quickly connect 



and disconnect with other , 

' ' ' ' object of the present invention to provide a personal ATM that is personal 




to a user. 



20 / It is ann?tiier object of the present invention to provide a personal ATM that is operative 

to store information for iTptef^lity of personal accounts belonging to a user. 
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is a flutter object of the present invention to provide a personal ATM that is operative 
to coordinate with anothei^AJTM to withdraw money. 

is a^feirther object of the present invention to provide a personal ATM that is operative 
to coordinate with anothehA^M to deposit checks 

It is a&rther object of the present invention to provide a personal ATM that is operative 

to transfer value between personal accounts, 
of the present invention to provide a personal ATM that is operative 
dispense^i^tems at a dispenser. 

of the present invention to provide a personal ATM that is operative 
f sale terminal to" transfer value, 
object of the present invention to provide an ATM that is operative to 




to coordinate with another 



itir 




lQl to coordinate 



; is 



upload a user interface applis^ion to another computer system for interfacing with the ATM. 
*^~)^Y/ X** /It is^a^rther object of the present invention to provide a personal ATM that is operative 
as a service to allow soJtw^re applications to interface with the personal ATM to perform 
transactions 

IHS^further object of the present invention to provide a Personal Digital Assistant 




operated as a personal^ATM. 



personal ATM 
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her object of the present invention to provide a cell phone operated as a 



her object of the present invention to provide a smart card operated as a 



personal ATM 
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It is a ftsther object of the present invention to provide a host ATM that is operative to 



interface with a persoha^ATM. 
*yi-vfl ^x^It^^fiirther object ofthe present invention to provide a host dispenser that is operative 
to interface with a phonal ATM. 

it is a mother object of the present invention to provide a point of sale device that is 
operative to interface wit^. a personal ATM. 
^7 L iS0 ^^^^ of the present invention will be made apparent in the following Best 

Modes for Carrying"Qut Invention and the appended claims 
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e foregoing objects are accomplished in one exemplary embodiment of the invention 
by an ATM thk includes a network for attaching devices. This network serves as the 
communication linfesbetween the ATM application software operative in the main computer 
system of the ATM and n^e transaction function devices that comprise functional elements in the 
ATM. Examples of such tran^ction function devices include cash dispensers, cash acceptors, 
card readers, depositories, and primers. However, the present invention encompasses a new form 
of these transaction function devices cah^d transaction services. Transaction services have 
properties of objects, similar to objects in object oriented programing languages such as C++ or 
Java®. Transaction services such as a print servic^, accept method calls remotely across the 
netwprk for performing such functions as printing text or delivering a printed receipt. In addition 
services can issue events remotely in other services. For example a printer service can invoke an 
event in an application program when the printer service is out orfjaper. ATM application 
programs can also include elements of an object oriented service. In tnis way all components 
whether hardware or software have properties of objects that adhere to the skne set of protocols. 



Thus the exemplary embodiment- of the present invention- is an ATM that, is created by 
assembling service objects. 

In the exemplary embodiment Sun Microsystems JINT™ defines the low level protocols 
used to configure transaction services on an ATM network. However, the present invention also 
encompasses other protocols such as Microsoft Universal Plug and Play™ that are operative to 
allow services in an ATM to automatically configure themselves on an ATM network and to 
communicate with each other with object method calls and events. 

In an exemplary embodiment of the present invention, services include a computer 
processing unit and memory for running a Java® Virtual Machine (JVM). In addition services 
include a nonvolatile data store such as a disk or NVRAM for storing hardware-independent 
Java® software proxy objects. These Java® proxy objects replace prior art hardware-specific 
device drivers for controlling the physical hardware. 

Prior art ATMs have an application software program that operates to cause the display of 
a graphical user interface, that receives inputs from input devices such as keypads and that 
controls the operation of the transaction devices such as a sheet dispenser. In the exemplary form 
of the present invention the application is itself a service. It interacts with other services such as 
a card reader service based on the JIN]™ protocols. The application service is operative to 
acquire one or more service proxy objects for each service that must be controlled by the 
application. These service proxies originate from the individual services themselves and are used 
by the application service to remotely control services across the network. In this manner each 
service contains all the software necessary to control its underlying hardware functions. No 
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longer is there a need for a service technician to install the correct drivers on the main computer 
of an ATM. Instead the correct service proxies are automatically updated from the service itself. 

Upon connecting a new transaction service to a network in an ATM, the service is 
operative to locate a special service on the ATM's network called a lookup service. This lookup 
service is responsible for registering each service on the network and storing a copy of each 
services' service proxy. This process of registering a new service on the ATM network is 
defined by "discover" and "join" protocols. After registration, other programs or services that 
need to communicate with or control the functionality of a particular type of transaction service, 
contact the lookup service and download the appropriate service proxy. The service proxy in the 
exemplary embodiment is a Java® object that is run in the JVM of the calling service. This 
service proxy defines the methods and events necessary to communicate with a service across the 
network. 

Because each service contains its own service proxy, when an old transaction service such 
as a cash dispenser is replaced with a new model, the service proxy for the new model is 
automatically installed and integrated in the ATM system. Consequently, the amount of time 
needed to update an ATM with newer services and the chances of installing incorrect drivers are 
reduced. 

Because the transaction services each contain their own individual JVM, they are also 
operative to load the service proxies of other services which will enable them to communicate 
and control other services directly. This feature is useful for services that are designed to work in 
tandem. For example, in prior art ATMs the application program controls each device. However 
devices do not control the application program. In the exemplary embodiment of the present 
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invention the application is a service. As such it has service proxies for each transaction service 
it has control over, such as a card reader service. However, because the application is also a 
service, the card reader may upload a proxy for the application that allows card reader to issue 
methods for controlling the application. 

For example, when a debit or credit card is first inserted into a card reader, the card reader 
can issue an application method using the application proxy to awaken the application service 
and pass attributes representative of the numbers encoded on the card. Such service to service 
communication is more efficient and easier to program than having the application constantly 
monitor the card reader for card insertions as in prior art ATMs. 

It is to be understood that services can be created that do not have the processing ability 
to run a JVM, For such services the protocols for configuring the service on the network may be 
programmed directly into the firmware of the service. 

Another advantage of placing services on a network, is that services can be attached to an 
ATM at greater distances. For example, rather than placing all the transaction services inside a 
single ATM enclosure, multiple groups of services can be configured on the same network. For 
example a bank could have one large private or virtual private network with multiple sets of 
ATM services located throughout a city. Each of the groups of services represents a single ATM 
workstation with an application service and multiple other transaction services. A special host 
service on the network could route banking transaction messages between the multiple ATM 
workstations and an external host network. 

An advantage of this system, compared to the prior art is that each service is an 
individually networked component, that can be easily replaced and updated dynamically. 
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Further, each component of the ATM can be remotely monitored, taken offline to 
troubleshoot without interfering with other services in an ATM or other ATMs on the network. 

Such dynamic connections have the advantage of allowing ATMs to connect to different 
types of services when needed. These on the fly connections make possible an alternative 
embodiment of the Jini enabled ATM in which the ATM is personal to an individual. This 
personal ATM can reside on any small portable computing device such as a notebook computer, 
cell phone, PDA, pager, or smart card. The personal nature of this embodiment allows an 
individual to store a plurality of their personal banking account information in a data store of the 
personal ATM. This alleviates the need to insert a banking card into the personal ATM to 
activate it. Instead, the personal ATM is inoperative until the personal password or other unique 
input of the owner of the personal ATM is entered and validated. 

When a user of the personal ATM desires to perform banking transactions, the user can 
connect the personal ATM to a network that offers the desired services. For example, if a user 
wishes to dispense cash, the personal ATM can be placed in operative connection with a Jini 
enabled host ATM that includes a cash dispenser service. The personal ATM can discover and 
join with the host ATM and use a proxy to the cash dispenser service to dispense cash. The 
personal ATM may be operative to prompt the user to select an account from which to receive 
the money and the amount desired. The information associated with the selected account and the 
amount desired are sent to the cash dispenser service with method calls of the cash dispenser 
proxy. -After validating the account information, the cash dispenser will dispense the cash and 
have the selected account debited. 
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Such a personal ATM can dynamically connect with banking services of a host ATM to 
deposit cash or checks and to transfer value between accounts. In addition, the personal ATM 
can connect to other types of devices that accept value as payment. For example, the personal 
ATM could connect with a Point of Sale (POS) service to transfer account information for 
payment of a bill. The personal ATM may connect with a Jini enabled dispenser service to pay 
for the dispense of items such as medication, snack foods, or any other item that dispensers and 
vending machines have to offer. The personal AT&Tof the present invention is operative to 
dynamically connect with any additional Jini service for transferring value from or to the service. 

BRIEF DESCRIPTION OF DRAWINGS 
Figure 1 is a schematic view of a first exemplary embodiment of an ATM system of the 
present invention. 

Figure 2 is a schematic view of a further exemplary embodiment of an ATM system of 
the present invention. 

Figure 3 is a schematic view of a further exemplary embodiment of an ATM system of 
the present invention. 

Figure 4 is a schematic representation of software components included in an exemplary 

service. 

Figures 5-8 schematically represent protocols for registering transaction services on an 
ATM network. 

Figure 9 schematically represents a discovery announcement protocol. 
Figure 10 is a schematic representation of an ATM bus service. 
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Figure 1 1 schematically represents a single ATM server computer that is operative to run 
an ATM interface application that controls the functionality of a plurality of Jini enabled ATM 
workstation services. 

Figure 12 schematically represents a personal ATM that is operative to perform banking 
transactions by connecting to various ATM services. 

Figure 13 schematically represents a plurality of personal ATMs that are operative to 
communicate with a host ATM for performing banking transactions. 

Figure 14 schematically represents a point of sale (POS) device that is operative accept 
payments from account information stored in personal ATMs. 

Figure 15 schematically represents a personal ATM on a smart card that is operative to 
use the input and output devices of a notebook computer to perform banking transactions with an 
Internet service of the notebook computer. 

Figure 16 schematically represents a personal ATM on a cell phone that is operative to 
perform transactions with another personal ATM on a PDA. 

Figure 17 schematically represents a dispenser that is operative to accept payment from 
account information stored in personal ATMs. 

Figure 18 schematically represents a personal ATM that is operative to perform banking 
transactions with services of a host ATM. 

Figure 19 schematically represents a personal ATM on a smart card that is operative to 
perform banking transactions with services of a host ATM. 

Figure 20 schematically represents the process of using a personal ATM when the 
personal ATM is first activated. 
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Figure 21 schematically represents the process of using a personal ATM on a smart card 
when the personal ATM is first activated. 

Figure 22 schematically represents the process of withdrawing money with a personal 
ATM in operative connection with a host ATM that includes a cash dispenser service. 

Figure 23 schematically represents the process of making a payment with a personal 
ATM in operative connection with a host. 

Figures 24 and 25 schematically represent the process of dispensing an item with a 
personal ATM in operative connection with a host dispenser. 

Figure 26 schematically represents the initial personal ATM interface menus of the 
personal ATM. 

Figure 27 schematically represents the personal ATM interface menus for transferring 
value between accounts with the personal ATM. 

Figure 28 schematically represents the personal ATM interface menus for withdrawing 
cash with the personal ATM. 

Figure 29 schematically represents the personal ATM interface menus for making 
deposits with the personal ATM. 

Figure 30 schematically represents the personal ATM interface menus for making 
payments with the personal ATM. 

Figure 3 1 schematically represents the personal ATM interface menus for dispensing 
items with the personal ATM. 

Figure 32 schematically represents the personal ATM interface menu for editing account 
information stored in the data store of the personal ATM. 
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BEST MODES FOR CARRYING OUT INVENTION 
Referring now to the drawings and particularly to Figure 1, there is shown therein, a 
schematic view of an ATM 10 that includes a number of transaction services, including an 
application 12 which is referred to herein as a user interface service. The exemplary ATM 
further includes a cash dispenser service 14, a print service 16, and a card reader service 18. 
Each of these services is connected to a common network 20. The ATM also includes a lookup 
service 22 that is responsible for registering new services on the network and providing a 
repository of service proxies of the services connected to the network. 

The ATM also includes a host service 23 that is operative to pass transaction messages 
between the ATM and an external network 25. Network 25 is connected to at least one host 
system 24 and preferably a plurality of host systems used in connection with banking systems or 
clearinghouses. Host system 24 is typically responsible for transaction processing related to . such 
tasks as validating a user's card and PIN numbers, debiting a withdrawal of money from a 
checking account and other transactions. 

Each service is operative to communicate with each of the other services through the 
network 20. One advantage of using a network to connect services in an ATM is that services 
are no longer limited to being connected to a proprietary ATM communication bus. Figure 2 
shows an exemplary embodiment of an ATM system with multiple groups of services in ATMs 
40, 42, and 44 connected to a common network 56. Each of these ATM services groups has the 
ability to communicate with a server computer 46 that is responsible for sending transaction 
messages 49 to an external host system 48 on behalf of each ATM services group. In this 
embodiment a lookup service 47 operates to register each ATM services group and includes a 
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program that resides on the server computer. However, in alternative embodiments the lookup- 
service may be an independent service attached to the network. In other embodiments each 
group of services in an ATM could have its own lookup service. 

ATM 40 is an exemplary embodiment of the invention in which services 50, 52, 54, and 
55 are independently connected to the network 56. In the exemplary embodiment the network 
may be an Ethernet network using TCP/IP protocol. Each service has its own IP address. The IP 
address for example could be automatically assigned or obtained from DHCP server. Each of the 
services in the group which is included in ATM 40 registers with the lookup service 47 and 
communicates through the network 56. 

ATM 42 is an exemplary embodiment in which only a network computer 58 is physically 
connected to the network 56. Examples of a computer that maybe used in this embodiment, 
include an Intel® based PC, a proprietary computer, a dedicated Java® workstation, or any other 
type of machine that is capable of connecting to a network, and running a JVM. The user 
interface service 64 and a local lookup service 63, are preferably Java® programs that run on the 
JVM of the network computer 58. However, such services and related service proxies can be 
generated from other languages and programing tools as long as the generated byte code executes 
in a JVM. Of course in other embodiments other types of virtual machines may be used. 

Transaction services such as a card reader service 60, print service 61, and a cash 
dispenser service 62 are connected to a network 66 that is. local to the network computer 58. 
This local network 66 could be based network topologies such as Universal Serial Bus (USB), 
Firewire DEEE 1394 or any type of connection that allows devices to communicate with each 
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other. A local lookup service 63 is responsible for registering local services attached to the local 
network 66. 

ATM 44 is an exemplary embodiment where only a user interface service 70 is in 
operative connection with the network 56. Transaction services such as a cash dispenser 72, a 
lookup service 77, and a printer service 75 are connected to a local network 80. Here however, 
some of the transaction devices such as a card reader 76 and a biometric scanner 78 are older 
legacy devices that do not have the characteristics of a transaction service. 

To accommodate these legacy devices in ATM 44, this embodiment includes a special 
bus service 74 which acts as a router between other services on the local network 80 and the 
legacy devices 76 and 78. The bus service 74 is operative in a manner similar to other services 
on the network, however, instead of having a single hardware function, it controls multiple 
hardware devices. From the point of view of other services, such as the user interface service, 
each of the legacy devices appears to be an independent service object. The bus service is 
responsible for translating and routing the service communication into the specific hardware 
signals needed to operate the legacy devices. 

Figure 3 is a schematic exemplary view of an ATM 90 with networked transaction 
services 108, 110, and 112. The system includes a network computer 100. The network 
computer is operative to execute a user interface service. The user interface service is operative 
to cause the display of a user interface output on an output service 102 such as a computer 
screen, and which accepts inputs from an input service 104 which includes a keypad, touch 
screen component or other input device. The network computer also includes a network interface 
109 for connecting to the common network 106 of the ATM. As discussed above this network 
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106 does not necessarily have to include an Ethernet type network. The present invention is not 
limited to any particular type of network for connecting services. Hence the network could be 
based on such architectures as the Universal Serial Bus (USB) or Firewire IEEE- 1394. 

In the exemplary embodiment each transaction service also conforms to the JINI™ 
specification. Each service includes a processor such as CPU 118 and a memory 120 for running 
Java® programs in a JVM. Exemplary service 1 12 includes a network. interface 1 14 for 
connecting to the network 106. The service also includes storage such as a disk, NVRAM 122 or 
other type of data store. The storage 122 is used to hold Java® objects and proxies which 
facilitate communication with other services on the network. The processor operates responsive 
to the stored programs. 

The software components that are included with each service are schematically 
represented for the exemplary embodiment in Figure 4. An exemplary service 130 used in 
connection with the present invention includes a JVM 140 which is operative to run programs 
written with Java® Development Kit® (JDK) Classes 142. Because transaction services typically 
perform a narrowly defined hardware function, a large portion of the JDK 142 does not need to 
be included with each service. JDK classes for building a graphical user interface are not needed 
in services such as a cash dispenser. Thus the JDK can be reduced in size to reduce the storage 
requirements of the service. 

The service 130 also includes a network configuration object 144 which in the exemplary 
embodiment conforms to the JUST™ registration specifications for "discovering" and "joining" 
with the network. As part of this discovery process the service 130 downloads a lookup service 
proxy 164 from a lookup service 162 which is located on the network with other transaction 
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services that comprise the ATM. A copy of this lookup service proxy 146 is stored with the 
service 130 and is used by the service to join the ATM network. 

During registration with the lookup service 162, the service 130 will upload a copy 166 of 
a service proxy 148 stored in association with service 130, to the lookup service 162. In the 
exemplary embodiment this service proxy 148 is a Java® object that enables other services or 
programs such as a user interface service 168 to remotely invoke methods of the service 130 
across a network. 

The service 130 may also include other software components such as a hardware control 
object 150 that includes methods for controlling the underlying hardware device functions 152 of 
the service 130. In the exemplary embodiment a service such as the user interface service 168 
causes its associated processor to operate to acquire the copy 170 of the service proxy 166 from 
the lookup service which serves as a repository for such proxies, and invokes methods of the 
copy of the service proxy 170 to have the hardware control object 150 operate the device 
hardware functions 152 of the service. 

Although the exemplary embodiment uses Java® objects running inside a JVM on each 
service, an alternate form of the service can be created that does not have a JVM. Such a service 
however, may have the instructions for interacting with a network that are hard coded into the 
firmware of the service. This approach may be appropriate for an inexpensive service that cannot 
justify the added expense of a dedicated CPU and memory. Unfortunately, the hard coding of 
methods for registration and security into firmware may limit the ability of the lookup service to 
evolve. Hence, such services may be designed to include a process for updating the firmware. 
Also future versions of the lookup service may maintain the same methods for registration and 
security so as to be able to continue to communicate with these hard coded services. 
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JVM enabled services do not have this limitation, because they can download an updated 
lookup service proxy during the discovery stage. Also JVM enabled services also have the 
ability to download and invoke the methods of service proxies for new or different type services. 

Figures 5-8 schematically show exemplary protocols for registering transaction services 
on an ATM network, and communicating with services. Figure 5 shows an exemplary 
embodiment of a "discovery" protocol 190. Here a service 200 has been newly connected to a 
network. The service has network configuration objects 202 that are operative to send a 
discovery request message 206 out on the network. This request 206 is preferably multicasted to 
all lookup services that might be present (in TCP/IP environments the network protocol used 
may be multicast UDP). In alternate environments, services may be operative to unicast a 
request to a specific lookup service using its known IP or URL address. 

The request 206 includes a source address 207 such as the IP address of the service 200. 
Each lookup service 208 on the network is operative to respond to the request message with a 
discovery response 210. Because the source address 207 of the service 200 is known, the 
discovery response 210 is not multicasted to all services, but is unicast directly to the service 
initiating the discovery. 

The response 210 includes a copy 212 of the lookup service proxy 209 for remotely 
invoking methods of the lookup service 208. In the exemplary embodiment the lookup service 
proxy is a Java® class with methods for: registering with the network; negotiating leases for the 
amount of time the service can be connected to the ATM network; and for looking up other 
services on the network based on a search criteria. 
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Figure 6 schematically represents a "join" protocol 220. Here the network configuration 
objects 202 of the service 200 invoke a registration method of the lookup proxy 212. This 
method is operative to send registration data 224 that includes a copy 226 of a service proxy 222 
and specific attributes 228 of the service to the lookup service 208. These attributes define the 
5 characteristic of the particular type of service. For example if the service is a printer, the 

attributes may specify that the printer is a color printer. The lookup service 208 preferably stores 
all uploaded service proxies in a proxy storage area 229. 

Once a service has joined the network, its service,proxy is available for other services on 

n the network to download. Figure 7 schematically represents a lookup protocol 230 of the 
vB 

1^ exemplary embodiment. Here a user interface service 23 1 invokes a lookup method of the 

^ lookup service proxy 233 that performs a search of a lookup service 232 for a specific service. 

l \Z The lookup search method arguments 242 include a type 244 of service that is desired and a list 

jL of specific attributes 246. For example, if the user interface service requires a connection to a 

W 

U color printer, the arguments 242 of the lookup search specify a service of type "printer" and 
15 attributes of "color". 

The lookup service 232 is operative to identify which of the registered services 236, 238, 
and 240 in the proxy storage 234 match the search arguments 242. The lookup service sends the 
results 248 of the lookup to the searching service 231. The results include a copy 250 of any 
matching service proxies (in this case a copy of printer service proxy 236) and corresponding 
20 attributes 252. 

Once a service has acquired a service proxy to a service, it may invoke methods and 
register for event notification from that service. Figure 8 schematically represents an exemplary 
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method for service to service communication. Here a user interface service 262 has obtained the 
service proxies 264 and 266 for two services: a printer service 268 and a card reader service 277. 

The user interface service 262 is operative to invoke method calls 274 and 282 from the 
service proxies which remotely invoke methods of hardware controller objects 270 and 278, 
respectively. The hardware controller object methods in turn control the functional hardware 
elements 272 and 280 of the respective services. For example, a print service proxy 264 for a 
printer service 268 has a print method with text data as an argument. Calling the print method 
will remotely call the corresponding print method on the printer service 268 which physically has 
the hardware 272 print out the text. 

The methods of the proxies do not necessarily correspond one to one with the methods of 
the hardware controller objects. The methods of the proxies can perform various types of 
validations or mjanipulations of the method arguments before remotely calling methods in the 
service. For example, the print methods for a printer service may accept images in bitmap format 
only. However, the corresponding print method of the proxy for the printer service may include 
addition processing functionality to convert images from other formats to a bitmap format before 
calling the remote functions of the print service. In addition the proxy methods may invoke 
combinations of remote methods in the service to perform the desired operation. 

In other embodiments such as where the printer service is in the form of firmware, the 
printer service proxy may be operative to send messages over the network with a proprietary 
protocol that, can directly control the printer hardware. 

In the exemplary embodiment of the present invention, services are also operative to have 
the service proxies register for event notification from the service. For example, the print service 
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may include a complete event. When the printer service 268 has completed printing text it calls 
this event. If the user interface has registered this event, the printer service 268 will send an 
event notification 276 to the user interface service remotely across the network whenever a 
printer operation is completed. 

As discussed above the user interface or application in the exemplary embodiment is also 
a service. Hence transaction services such as a card reader service 277 are operative to remotely 
invoke method calls 288 and register for event notification 290 with the user interface service. 

A card reader service 277 of the exemplary embodiment is operative to acquire a user 
interface proxy 286 from a lookup service. This proxy will allow the card reader to invoke 
methods of the user interface such as an activation method, when the card reader first detects that 
a card is inserted into the reader. 

In the exemplary embodiment the method for calling methods remotely from one service 
to another, and invoking events remotely is a function of the Java® Remote Method Invocation 
(RMI) classes in the JDK. The RMI protocol facilitates the ability of a service to invoke methods 
of another service across a network. RMI allows both data and full Java® objects to be passed 
from one service to another. 

One of the advantages of using RMI for communicating with services across the network 
of an ATM, is that the physical hardware of a service appears from the programmer's point of 
view as just another Java® object with methods for performing certain functions. Such a system 
is much easier to develop and modify, because the programmer of an ATM user interface no 
longer is required to understand all the intricacies of the low level hardware of a service. 
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In the exemplary embodiment, the configuration of the apparatus and system is 
automatically changed in response to the connection and removal of services. As previously 
discussed, each service that is connected to the ATM, registers with a lookup service (and/or 
other services) through operation of the processors associated with each service. This 
registration is effective for a period of time which is referred to as a "lease". When the lease 
expires the service (if it is still connected) reregisters and thereby negotiates a new lease with the 
lookup service and/or other services. If the service is disconnected the current lease expires and 
is not renewed. When this occurs the service is automatically eliminated from the ATM 
configuration. Preferably the lease periods are set so that removed services cease to be registered 
before methods thereof are attempted to be invoked. For example in some ATM embodiments it 
may be desirable to require each service that is present to negotiate a new lease at the start of 
each transaction so that the configuration of available services for carrying out the transaction is 
determined. Of course other lease periods, and lease periods which differ depending on the 
character of the particular service may also be used. 

The embodiments discussed above have a lookup service that is responsible for 
registering services on the network and which serves as a repository for service proxies. In 
alternate embodiments of the present invention the ATM may be operative to function without a 
lookup service. Figure 9 is a schematic representation of a discovery announcement protocol 
350, In the discovery announcement protocol a user interface service 352 is operative to initiate 
the discovery process between itself and other services on the network, whereby the user 
interface acquires a service proxy 354 directly from individual transaction services 358. 

When the user interface service 352 is first connected to the network and periodically 
thereafter, it is operative to multicast a discovery announcement 362 across the network 364 
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which requests that services on the network begin the discovery process and register with it. 
Interested services upon receiving this announcement are operative to unicast a discovery request 
366 directly to the announcing user interface service 352 rather than to a lookup service. The 
user interface service then participates in the "discover/' and "join" processes just as if it were a 
lookup service. 

In addition this discovery announcement protocol 350 can also be used by a lookup 
service, in cases when a lookup service is added to a network with preexisting services. In this 
case the lookup service can announce its presence on the network with, the discovery 
announcement so that services will register with it. 

The exemplary embodiment of the present invention includes services that are fully 
capable of configuring themselves on the network. However, for legacy services or new services 
that do not have a network interface, a special bus service can be employed as discussed above. 
Figure 10 is a schematic representation of an ATM bus service 300 that enables the connection of 
devices 302 and 304 (in this case a printer and a cash or sheet dispenser, respectively) that do not 
include object oriented and networkable features. 

Here bus service 300 includes all the elements of other transaction services. It includes a 
CPU 306, a memory 307, storage 312, and a JVM 3 14 for running Java® programs for 
discovering and joining a network. For legacy devices the service bus may come pre-loaded with 
multiple service proxies for each hardware service that can be physically attached to the service 
bus. Physical attachment may be with an RS 232 serial connection for example, or via a 
proprietary connection. The service proxies are uploaded to the lookup service during the join 
process of the bus service. From the point of view of other services on the network, all of the 
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legacy services appear to be objects capable of receiving remote method calls. The bus itself 
handles the routing of messages between the network and the legacy services. 

In this described embodiment of the bus service 300, the devices 302 and 304 include 
storage for downloadable software objects. As shown schematically with reference to printer 
device 302, this storage 309 is used to hold service proxy 308 and a hardware controller object 
310. The bus service 300 is operative to download a copy of the service proxy 312 and a copy of 
the hardware control object 311 from the device 302. When the bus service connects to a lookup 
service 315, the bus service is operative to upload a copy of the service proxy 312 to the lookup 
service 315 using the discovery and join protocols as discussed previously. Other services on 
the network may then acquire a copy of the service proxy from the lookup service 315. 

The bus hardware controller object 3 1 1 runs in the JVM 3 14 of the bus service 300 and 
has methods for controlling the physical hardware of the device 302. When the user interface 
service 316 invokes a service proxy method call 318 across the network 317, the bus hardware 
controller object 315 executing in the JVM 314 is operative to control the device 302. From the 
point of view of the user interface service 316 or another service on the network, the devices 302 
and 304 appear to be object oriented services. 

The devices for this bus service 300 are a hybrid between the complete slave legacy 
devices of the prior art and the full network enabled services. These hybrid services include their 
own service proxies, but do not require a CPU and memory for running a JVM. Although they 
have a lower cost to produce, they are intimately tied to the bus design. Also, the bus hardware 
must have a specific connection for each type of device. 
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One of the advantages of an ATM with networkable transaction services, is that the form 
of the ATM is flexible. Prior art ATMs are limited in the number of serial and parallel ports that 
are available for connecting peripherals. When all the ports are filled, a new communication card 
with additional ports must be installed in the ATM. An ATM that uses networkable transaction 
services can scale to include as many services as the bandwidth of the particular network 
topology can handle. With an Ethernet network based on 10-base-T for example, theoretically 
hundreds of Jini enabled devices could be connected to the network of an ATM. Of course a 
prior art ATM would rarely require more than a dozen or so peripheral devices. However, the 
ability to easily connect a large number of transaction services creates new opportunities for 
designing ATMs. 

Figure 1 1 shows an alternative embodiment of an ATM 380 in which a single ATM 
server computer 382 is in operative connection with a network 384 that connects a plurality of 
different ATM workstations 386, 388, and 390. Each ATM workstation comprises a set of 
transaction services. However because, each service is in network communication with a 
common server computer 382, all three ATM workstations 386, 388, and 390 can be controlled 
by a single Jini enabled application 392. This application 392 uses service proxies for each 
transaction service to control the functionality of each of the three ATM workstations. 

In this example the ATM workstation 386 includes an output service 394 which includes 
a graphical display, an input device service 396 such as a keypad, a cash dispenser service 398, a 
print service 400, and a card reader service 402. Each of these services is Jini enabled and are 
operative to discover and join with a lookup service 404 when the services are first installed on 
the network 384. The application service 392 controls each service, and is operative to have an 
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independent ATM interface be displayed with each of output service 394 and output services 406 

and 408 on ATM workstations 388 and 390 respectively. Thus a single ATM server 382 can 

manage a plurality of independently operable ATM workstations. 

Such a design offers advantages over prior art designs. To upgrade the interface menus 
5 for each ATM workstation, only the application service 392 located on the ATM server 382 

needs to be upgraded. This design offers centralized configuration, management, and security, 

and allows the physical components of each ATM workstation to be easily upgraded by replacing 

or plugging in additional Jini enabled transaction services. 
c ^ The. exemplary embodiments of the ATMs previously discussed have primarily been 

fig concerned with using Jini protocols to produce an improved ATM comprising networkable 
1^ transaction services. However, the ability to configure an ATM without requiring an operator to 
I** load new device drivers from a CD-ROM for example, offers the unexpected benefits of 

producing an ATM that can be configured on the fly depending on the needs of its owner. Hence 

t . 5 

^ an alternative embodiment of the ATM of the present invention is one that is portable and that 
f£| connects to transaction devices as needed. Such an ATM could be personally owned by a private 
individual and be used to conduct personal banking transactions, to pay for purchases, and to 
store electronic money. Further, personal account information relating to credit cards, utility 
customer numbers, medical plan numbers, debit cards, and information corresponding to any 
other type of account that money or value is either transferred to or from, can be stored in the 
20 personal ATM. In addition, the inclusion of multiple types of account information and means for 
storing value in a single personal ATM, reduces the need for a person to carry numerous types of 
credit and banking cards.' 
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For this embodiment a portable device that is operative to run a JVM and to connect to a 
network using discovery/join/lookup protocols such as Jini, can be used. Examples include a 
notebook computer, a cell phone, a pager, and a Personal Digital Assistant (PDA). As a personal 
ATM, such devices are configured to run a personal ATM service application that performs 
banking operations as is done at non-portable ATM workstations. Unlike prior art ATMs, these 
portable devices do not include attached currency dispensers. However, because the personal 
ATM service is Jini enabled, it can connect to additional transaction services as needed, such as a 
cash dispenser service of a Jini enabled public or multi-user ATM workstation. Such a public or 
multi-user ATM that is operative to allow personal ATMs to connect to it is referred to herein as 
a host ATM. 

Figure 12 shows a schematic representation of an exemplary personal ATM 500. The 
personal ATM 500 is shown in connection with various types of transaction services. Some of 
these transactions services are local connections to the physical personal ATM including a print 
service 502 such as an attached printer, a modem service 510 such as an attached PC card 
modem, and a card reader service 512 such as a smart card reader. The printer service can be 
used to print banking transaction receipts or even full account statements. The modem service 
can provide a connection to a dedicated host banking system such as an online banking system 
clearinghouse through which a user can accomplish transactions such as transfers of money 
between accounts, payment of bills or purchases of goods or services. The card reader service 
512 can provide access to a smart card for storing electronic money, or to read the account 
information from a magnetic-stripe card or other article. 
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The personal ATM 500 can be temporarily connected to another Jini enabled ATM that 
includes additional services. An exemplary host ATM 504 can provide access to services for 
withdrawing cash from a cash dispenser service 516, for depositing cash with a cash recycler 
service 518, and for depositing envelopes with an envelope deposit service 520. Further if 
desired and/or if the personal ATM does not have its own modem service, the host ATM 504 can 
provide access to a host banking system service 522. The host ATM can also provide access to 
other types of services not included with the personal ATM. For example, if the personal ATM 
500 does not have its own card reader, the host ATM 504 can provide access to a card reader 
service 514. 

The personal ATM 500 can temporarily connect to other types of host machines which 
provide services. Examples include a point of sale (POS) service 506 which may be a part of a 
payment terminal located in the checkout line of a grocery store, a medical item dispensing 
machine service 524 located at a pharmacy, a medical payment terminal located in a doctor's 
office, or even someone else's personal ATM service 526. Such connections allow the personal 
ATM to directly pay for purchases by transmitting information which identifies the user's 
personal credit card or debit card accounts stored locally in a data store 528 in the personal ATM 
500. The personal ATM may also be operative to store electronic money in local memory in an 
encrypted format, and may transfer the electronic money to a connected service such as the 
medical dispenser service 524 to pay for a dispensed medical item. For personal ATMs that have 
access to the Internet, an Internet service 508 can provide access to a host banking system service 
530 or a bill paying service 532. 
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The examples of computing devices such as cell phones and PDAs that may be suitable 
for use as a personal ATM typically include local displays and input devices. However, the 
present invention also encompasses other computing devices such as smart cards which do not 
have displays and input devices. Any smart card that includes a CPU, memory, and a non- 
5 volatile storage for running a JVM, or includes dedicated firmware for interacting with other 

services using Jini protocols, or other comparable components and features, may also be used as 
the computing system of the personal ATM of the present invention. 

To interact with a personal ATM on a smart card, the smart card can be put in operative 
connection with an output service 536 such as a display screen and an input service 534 such as a 

O 

. » 

tf keypad, hi the preferred exemplary embodiment this is accomplished by inserting the smart card 
into a smart card reader of a Jini enabled host ATM or some other host machine that includes a 

F — 

%1 display and input device. An example of such a machine is a notebook computer. Once 

CO ■ 

= connected, the smart card can use the discover/join/lookup protocols to pass service proxies 
O 

™ between itself and the host machine. 

£jf In one exemplary embodiment the smart card downloads proxies for the display and input 

services of the host computer. These proxies are used by the personal ATM service(s) in the 
smart card to display an ATM menu screen on the output service of the host machine, and to 
receive input signals from the input device of the host machine. 

In an alternative embodiment, rather than downloading display and input services, the 

20 personal ATM service(s) on the smart card uploads a personal ATM proxy service(s) to the host 
machine. This proxy includes a Java interface application which runs in the JVM of the computer 
system of the host machine. The Java application creates a user interactive ATM menu interface 
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which displays on the output device of the host machine and accepts inputs from the input device . 
of the host machine. 

This described embodiment divides the functionality of the personal ATM across 
different computer systems. The personal ATM service(s) on the smart card may perform back- 
end operations of maintaining a data store of accounts, validating passwords, and/or storing 
electronic money, whereas the host computer executes the front-end interactive GUI application 
for interfacing with the personal ATM service(s) on the smart card as well as other services. 

Figure 13 schematically represents a Jini enabled host ATM 540. This host ATM is 
operative as a stand alone ATM terminal and includes services such as a cash dispenser 541. 
However, host ATM 540 also includes one or more external network ports 550 that allow 
personal ATMs to connect with the host ATM. These ports 550 provide an access point for Jini 
enabled cell phones 542, notebooks 544, pagers 546, PDAs 548 and other devices that are 
operative as Jini enabled personal ATMs, which enables such devices to use the publicly 
available services of the host ATM. Once a personal ATM has discovered and joined with the 
Jini network of the host ATM, the personal ATM is operative to lookup and interact with 
available services, such as the cash dispenser 541. 

For a personal ATM on a smart card, the host ATM includes a smart card interface 554 
such as a smart card reader or a contactless interface for communicating with the card. Once the 
smart card is in operative connection with the host ATM, the service(s) on the smart card is 
operative to discover and join with the Jini network associated with the host ATM, just as the 
other described personal ATM computing devices. 
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The personal ATM on a smart card uses the display 556 and keypad 558 of the host ATM 
540 to generate an interactive ATM interface menu for enabling interaction with a personal ATM 
service or several services on the smart card. For computing devices with built in displays, such 
as the PDA 548, the personal ATM user interface can be produced on their own display screen 
5 549. Alternatively, such devices can use the display and keypad of the host ATM 540, as is done 
by the smart card personal ATM 552. 

Once a personal ATM is connected to the host ATM 540, it may be operative to interact 
to perform such tasks as withdraw cash, receive deposits, and to transfer money to and from any 
of the accounts for which data is stored in the personal ATM and/or for which data representative 
W of electronic money is stored in connection with the personal ATM. 

L Figure 14 schematically represents embodiments of personal ATMs 560 and 562 that are 

t± operative to discover and join with a Jini enabled host Point of Sale (POS) service which resides 
s_ on a POS terminal 564. Once connected to the POS service, the personal ATM is operative for 
Yf example to pay for purchases by transferring account information stored in the data store of the 
|S personal ATM to the POS service. 

Figure 15 schematically represents embodiments of personal ATM 566 that is resident on 
a smart card. Personal ATM 566 may be placed in operative connection with a Jini enabled 
computing device such as host notebook computer 568 through an appropriate interface. Once 
the personal ATM 566 has discovered and joined with the notebook computer 568, the notebook 
20 computer is operative to lookup the personal ATM proxy for the personal ATM. This ATM 
proxy is operative to display a Java based ATM user interactive menu on the notebook display 
569. In addition, services of the notebook, such as an Internet connection service 570 are 

35 



available for use by the personal ATM 566. The ATM proxy is operative to enable menu options 
for performing banking or other transactions such as transferring money between accounts and 
paying for purchases by using the Internet service 570 of the notebook 568. 

Figure 16 schematically represents an embodiment of the personal ATM 572 that is 
5 operative to discover and join with the Jini network of a second personal ATM 574. In this 

manner the first personal ATM 572 is enabled to transfer data representative of electronic money 
to the second personal ATM 574. Also, each personal ATMs could share services with the other 
for purposes of carrying out transactions. 

^ Figure 17 schematically represents a Jini enabled host dispenser 578 that dispenses 

r L1 = 

fig medical items. Host dispenser is operative to have personal ATMs 576 and 580 discover and 
join with it. The dispenser 578 includes a dispenser proxy which includes an interactive Java 
[>« application for selecting items to purchase and dispense. For personal ATMs that include their 
own local display services, the dispenser proxy interface application can be uploaded and 

* s I 

executed in the local JVM of the personal ATM. In other embodiments, as with embodiments of 
the personal ATM on a smart card, the dispenser interface application executes in the computing 
system of the dispenser and is operative to interact with the personal ATM through the personal 
ATM proxy. * 

Once a user has selected items to purchase with the dispenser proxy interface application, 
the personal ATM service is triggered by the dispenser service to make payment. This may be 
20 accomplished by either transferring electronic money or by providing credit/debit account 

information stored in the personal ATM. This information is used to accomplish payment and an 
appropriate record is made in the dispenser and the personal ATM. 
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Figure 18 schematically represents a personal ATM 582 in operative connection with a 
host ATM 584. Here the personal ATM includes a computing device 581 with a processor such 
as a PDA or cell phone with a local display screen 596. The personal ATM is operative to run a 
JVM 586 with a JDK 588 and Jini Classes 590. The personal ATM also includes a data store 592 
5 that includes account information for credit cards, debit cards, and any other account which is a 
source of value. The personal ATM 582 further includes a personal ATM service 594 that is 
operative to output an interactive ATM interface menu 598 on the display screen 596. 

The personal ATM 582 is operative to discover and join with the host ATM 584 which 
includes an ATM lookup service 600 and other transaction services such as a cash dispenser 
jU service 602, cash recycler service 604, and banking network service 606. The personal ATM is 

further operative to cause the processor to operate to look up these public services and to 
M download corresponding proxies such as proxy 608. The personal ATM uses these proxies to 

£ a a 

s interact with the host ATM responsive to human interaction with the ATM interface menu 598 of 
s fj the personal ATM 582. 

ti In this described exemplary embodiment the personal ATM service 594 is operative to 

generate a user interface menu 598 responsive to the types of public services that are available at 
host ATM 584. However, in alternative embodiments, the personal ATM may display a user 
interface menu that originates from the host machine. For example, when the personal ATM 582 
joins with the host ATM 584, the personal ATM may lookup and retrieve a high level host ATM 

20 service proxy that encapsulates the functions of all of the publicly available services of the ATM 
host. Such a high level service proxy may include the necessary programming to display a user 
interface menu 598 with the display screen 596 of the personal ATM 582 for having the host 
ATM 584 perform a plurality of different types of transactions. 
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In another alternative embodiment the personal ATM may include a browser software 
function 599. The high level host service proxy may direct the browser 599 to retrieve from the 
host ATM 584 one or more user interface pages 601 for display in the browser 599. Such user 
interface pages 601 may include Hyper Text Markup Language (HTML), Extensible Markup 
Language (XML), Wireless Markup Language (WML), Java script, and any other type of 
instruction language that is operative to have the browser 599 output m interactive interface 598 
with display screen 596 of the personal ATM 582. 

It is recognized that different types of personal ATMs may have different types of display 
screens 596 with different performance characteristics. For example, a notebook computer may 
have a relatively large high resolution graphic display, whereas a cell phone may have a small 
low resolution character-based display. To accommodate either type of display, the exemplary 
embodiment of the present invention is operative to format the interface menu 598 responsive to 
the specifications of the display screen 596. For example if the interface menu 598 is generated 
by a high level service proxy, the service proxy is operative to output indicia for the interface 
menu 598 in a format that is appropriate for the display screen 596. If the interface menu is 
displayed in a browser responsive to interface pages, the personal ATM is operative to retrieve 
interface pages from the host ATM 584 that correspond to the display characteristic of the 
display screen 596. 

This may be achieved by a host ATM that includes a plurality of different service proxies 
that correspond to different types of display screens. For example the host ATM may include 
service proxies for character based cell phone display screens and service proxies for graphical 
VGA display screens. The personal ATM may lookup and retrieve the service proxy that 
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matches its particular resolution. In an alternative embodiment, the service proxy may be 
operative to determine the resolution of the display screen 596 when it is executed in the JVM 
586 of the personal ATM 582. Based on this determination the service proxy may then construct 
and output a properly formatted interface menu 598 responsive to the determined resolution of 
the display screen. ^ — \ 



For embodiments of the v jae£fATM that include a browser 599 for displaying interface 
pages, the host ATM may include different sets of these interface pages which are formatted for 
different resolutions and/or types of personal ATM display screens. Once the personal ATM has 
joined with the host ATM, the personal ATM is operative to retrieve the proper set of instruction 
pages responsive to the type of display screen that is being used. 

Figure 19 schematically represents an alternative embodiment in which the personal 
ATM 610 resides on a smart card computing device 612. Here the personal ATM 610 is in 
operative connection with a host ATM 614. However, rather than downloading proxies to the 
various transaction services 616, 618, and 620 from the host ATM 614, the personal ATM 610 
uploads at least one personal ATM proxy 622 that is operative in the JVM 624 of the host ATM 
614. The personal ATM proxy includes a Java ATM interface application that is operative to 
output an interactive ATM interface menu 626 on the display screen 628 of the host ATM 614. 

The personal ATM proxy 622 is also operative to remotely call personal ATM object 
methods of the personal ATM service 630 operative in the JVM 632 of the personal ATM 610. 

In this exemplary embodiment, the personal ATM comprises any computing device that 
includes a CPU, memory, and non- volatile storage operative to run a JVM, wherein Java objects 
running in the JVM are operative to discover and join with a network. However, other 
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embodiments of the personal ATM may employ firmware that is specifically designed to 
interface with services on a network using discover and join protocols such as Jini. Other 
embodiments of the personal ATM may employ other networking protocols and systems that are 
operative to have devices automatically configure themselves on a network by passing internally 
stored device drivers across the network. 

Figure 20 schematically represents the process by which a personal ATM such as the 
personal ATM shown in Figure 1 8 initially operates. In this embodiment, the computing device 
includes its own local display screen. The personal ATM computing device is first activated by 
either manually activating the device on in step 700, or activating the device by some other 
method such as sensing a network connection. Once activated, the personal ATM is operative to 
execute the personal ATM service in step 702. The personal ATM service is an application 
which is either manually started by the user of the apparatus, or is automatically started by the 
operating system of the personal ATM computer. 

Next the personal ATM service displays a login screen in step 704 which requires the 
user to enter a password which serves as validating data. In embodiments of the invention the 
validating data may include a code, thumb or finger prints, iris or retina scans or other biometric 
or other data that is capable of identifying a user, or combinations of such inputs. After a user 
enters a password in step 706, the personal ATM service validates the password in step 708. If 
the validation fails the personal ATM service jumps to step 706 and redisplays the login screen. 
If the validation succeeds the personal ATM service discovers and joins with a lookup service on 
the network in step 710. After joining the network, the personal ATM performs a lookup of 
available services on the network in step 712. The personal ATM in step 714 displays a list of 
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selectable menu items in a personal ATM main menu screen. This list corresponds to the types 
of services that are available. For example if the network includes a cash dispenser, the personal 
ATM service will display a menu item for withdrawing cash. In step 716 the personal ATM 
service waits for a user to select one of the menu items. 

5 Figure 21 schematically represents the method steps that are employed with a personal 

ATM as described with reference to Figure 19. Here a personal ATM comprising a smart card is 
activated in step 720 by inserting the card into a smart card interface of a host machine. In an 
exemplary embodiment both the card and the host machine would use Jini protocols to configure 

C3 and communicate with each other; however, alternate embodiments can use other network 
l|S protocols operative to allow the smart card to automatically upload a personal ATM interface 

L™ application to the host ATM. As discussed above, examples of host machines can include Jini 

E = 

f II enabled ATMs, dispensers, notebook computers, point of sale devices, and other personal ATMs, 
p Once activated, the smart card in step 722 performs Jini discovery and join with the 

S 8 * . lookup service of the host machine. As part of the join process the personal ATM uploads at 
\W least one personal ATM proxy to the host machine. In step 724 the host machine runs the 

personal ATM proxy in the JVM of the host machine which is operative in step 726 to display a 
login screen on the output device of the host machine. After the user enters a password or other 
validating data in step 728 through at least one input device of host machine, the personal ATM 
proxy in step 730 remotely calls a validate method of the personal ATM service running in the 
20 JVM of the smart card. This validate method is operative to test for validity of the identifying 

data entered in the host machine input service by comparing the identifying data with data stored 
in a data store of the smart card. The personal ATM service is further operative to pass the 
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results of the validation test back to the calling personal ATM proxy. If the validation test failed 
the personal ATM proxy redisplays the login screen at 726 and waits for a user to reenter 
validating data. If the validation test succeeded as a result of correspondence between input data 
and stored data, the personal ATM proxy in step 734 performs a lookup of available Jini services. 
In step 736 the personal ATM proxy displays a personal ATM main menu on the output device 
of the host machine responsive to the types of available services. In step 738 the personal ATM 
proxy waits for a user to select one of the menu options with the input service of the host 
machine. 

In the described embodiment, the personal ATM proxy includes its own Java application 
for displaying an ATM menu. However, in other embodiments, the host machine can include its 
own interface application. This host interface application would request that the user input 
validation information. To validate a password for example, the host application calls the 
validation method of the personal ATM service in the smart card using the object functions of the 
personal ATM proxy. To perform other transactions which require data stored on the smart card 
the host application may call other methods of the personal ATM proxy to retrieve this data. 

Figures 22-25^are exemplary methods for using the personal ATM to withdraw cash, to 
pay a bill, and to dispense a medical item. All of these methods continue from the point where 
the personal ATM is displaying the personal ATM main menu. These methods are applicable for 
either of the processes described in Figures 20 and 21. For embodiments that use a computing 
device such as a PDA, the personal ATM menu is displayed on the local output device of the 
PDA. For smart card embodiments, the personal ATM menu is displayed on an output device of 
the host machine. 
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. Figure 22 shows the process for withdrawing cash from a host ATM. In a step 750 the 
ATM menu option for withdrawing cash is selected by the user. For this menu option the 
personal ATM displays a "withdrawal from" menu in step 752 which lists the available accounts 
for which information is stored in the data store of the personal ATM.. Such accounts can include 
5 checking, savings, credit, debit, money market or any other account from which a host ATM is 
operative to deduct value. The personal ATM can include local data stprage representative of 
accounts for electronic money, food stamp credits, college cafeteria points or any other type of 
stored value which is transferred from the personal ATM to the host ATM. 

After the user selects an account in step 754, the personal ATM requires the user to enter 

: 5 

1^ a withdrawal amount in step 756. Next the personal ATM in step 758 sends the account 

nisi; 

M/ information associated with the selected account and the withdrawal amount to the host ATM by 

M 1 calling withdraw methods of a cash dispenser proxy. 

;L The host ATM is operative to validate the account information. If the withdrawal 

r: validation fails the host ATM triggers a validation event or method in the personal ATM with a 

r~ 

lr| false value in step 762. Consequently the personal ATM in step 764 displays an error message 

l £_ 

T 

and returns to step 752 to display the "withdrawal from" menu. 

If the withdrawal validation succeeds in step 766 the host ATM dispenses cash with the 
cash dispenser and has the withdrawal debited from or charged to the selected account. In step 
768 the host ATM triggers the validation event or method in the personal ATM with a true value, 
20 wherein the personal ATM is operative to jump back to the steps 714 or 736 in Figures 20 and 21 
respectively to display a refreshed personal ATM main menu. 
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Figure 23 is representative of a method for paying value with the personal ATM in 
connection with a host POS service. In step 780 a user selects a "pay bills" menu item from the 
main menu of the personal ATM. The personal ATM in step 782 displays a "payment to" menu 
with a list of POS terminals that the personal ATM is currently in connection with. After the 
user selects a POS terminal in step 784, the personal ATM displays a "payment from" menu with 
a list of accounts in step 786. After the user selects an account in step 788, the personal ATM 
retrieves the payment amount in step 790 from the host POS by calling POS service object 
methods of the POS proxy. 

The personal ATM displays this amount in step 800 and requires the user to confirm that 
this amount is correct. If the amount is confirmed the personal ATM sends the selected account 
information in step 802 to the host POS by calling methods of the POS proxy. In step 804 the 
host POS validates the transaction using the account information. If the payment is not validated 
the POS triggers a validation event or method in the personal ATM with a false value in step 
806. Consequently in step 808 the personal ATM displays an error message and returns to step 
786 where the personal ATM displays the "payment from" menu. 

If the validation succeeds in step 810 the POS triggers the validation event or method in 
the personal ATM with a true value and the personal ATM returns to the steps for looking up Jini 
services and redisplaying the personal ATM main menu. 

Figure 24 is representative of the method steps for dispensing medical items from a 
dispenser with the personal ATM. After a user selects the "dispense" menu in 820 from the main 
ATM menu, the personal ATM displays in step 822 a "dispense" menu with a list of host 
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dispensers available on the Jini Network. If the personal ATM is only in connection with one 
host dispenser service, the personal ATM is operative to jump from step 820 to step 826. 

When a user selects a host dispenser service in step 824 the personal ATM downloads a 
proxy to the selected dispenser. In one exemplary embodiment, the dispenser proxy includes a 
Java application that is operative to generate a dispenser interface for interacting with the host 
dispenser service. In alternative embodiments, the dispenser proxy may be operative to have the 
browser of the personal ATM display interface pages retrieved from the dispenser that 
correspond to a dispenser interface. In embodiments of the personal ATM on a smart card, the 
dispenser interface is displayed on the output device of the dispenser. When information such as 
user identifying information, an account number or credit card number is required, the dispenser 
is operative to communicate with the personal ATM service on the smart card through a personal 
ATM proxy. 

The dispenser interface application in one exemplary embodiment is an interactive user 
interface which includes functionality to allow a user to select items to dispense. Such a 
dispenser interface will typically display items available to dispense prescription data, items 
selected to dispense, the cost of each item, the total costs of all selected items and/or any other 
information which may be appropriate and useful for making purchases or obtaining medical 
items from a dispenser. In exemplary embodiments of the invention these items may be a subset 
of items available in the dispenser which have been prescribed for the particular user of the 
personal ATM by a physician or other medical provider and which are selected responsive to a 
prescription service in connection with the dispenser. Alternatively, the principles of the 
invention may be applied to systems like that shown in U.S. Patent No. 5,912,818 which is 
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incorporated herein by reference, in which a medical professional dispenses items for selected 
patents and records are maintained regarding what the user has taken and each patient has 
received. Charges may also be appropriately assessed to the patients and inventory may be 
tracked and restocked as required. 

In addition the complexity of the dispenser interface may be generated responsive to the 
type or resolution of the display device of the personal ATM. For example, if the personal ATM 
is a cell phone the dispenser interface may be limited to alphanumeric characters, whereas if the 
personal ATM is a notebook computer the dispenser interface may include complex graphics. 

In step 828 the user interacts with the dispenser and selects items to dispense. When the 
user is finished selecting items to dispense, the dispenser interface in step 830 triggers a get 
payment account event or method of the personal ATM. Consequently in step 832 the personal 
ATM displays a "payment from account" menu with a list of available accounts to pay for the 
dispense of the selected items. 

After the user selects an account in step 834, the personal ATM retrieves the payment 
amount from the host dispenser service with a method call of the dispenser proxy. In step 840 
the personal ATM has the user validate that the payment is correct. If the payment is not 
validated, the personal ATM jumps to step 826 and redisplays the dispenser interface. 

Figure 25 is a continuation of the method steps for dispensing items from a host dispenser 
service as shown in Figure 24. Here if the payment to the dispenser is confirmed by the user, the 
personal ATM in step 842 sends the selected account information to the host dispenser service 
using methods of the dispenser proxy. In step 844 if the host dispenser service does not validate 
the transaction, the host dispenser service is operative to trigger a validation event or method of 
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the personal ATM with a false value in a step 846. Consequently the personal ATM in step 848 
displays a corresponding error and jumps to step 832 of Figure 24 for displaying the "payment 
from account" menu. 

If the transaction is validated by the host dispenser service, the host dispenser service in 
step 850 dispenses the purchased item. In step 852 the dispenser triggers a validation event or 
method of the personal ATM with a true value. Consequently the personal ATM jumps to the 
steps for looking up Jini services and redisplaying the main menu. 

Figure 26 shows screens representative of the ATM interface menu of the personal ATM. 
a personal ATM main menu 900 in this exemplary embodiment includes menu items such as 
transfer 902, withdrawal 904, deposit 906, pay 908, dispense 910 and other 912. These items are 
visible responsive to the types of services that the personal ATM is in connection therewith. For 
example if the service is not in connection with a host ATM service that includes a cash 
dispenser service, the withdrawal menu item 902 will not be visible. 

Selecting the "other" menu item 912 for this exemplary embodiment displays a second 
personal ATM "other" menu 914, which includes other features and maintenance options of the 
personal ATM. Such menu items include editing accounts 916, lookup of other Jini services 
918, configure services 920, lookup/print account statements 922, change password 924, and 
update personal ATM 926. The editing accounts menu item 916 enables maintaining account 
information in the data store. The lookup other Jini services menu item 918 when selected 
initiates the Jini lookup of services on the network. The configure services menu item 920 when 
selected causes the display of further menus which enable the configuration of the services. The 
lookup/print account statements item 922 when selected enables the reviewing and printing of 
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account statements. The change password menu item 924 enables the user to change the main 
personal ATM password. The update personal ATM menu item 926 enables the downloading of 
a new version of the personal ATM service and supporting software from the Internet or a host 
ATM. 

When the personal ATM is in operative connection with a host ATM or has access to an 
Internet based host banking system service, the personal ATM may be operated to transfer money 
between accounts. Figure 27 is representative of exemplary transfer menus of the personal ATM. 
The "transfer to" menu 930 includes a list of accounts for which data is stored in the data store of 
the personal ATM. One of these accounts can be selected for transferring value to an account. 
After selecting a "transfer to" account, the personal ATM is operative to display a "transfer 
from" menu 932. This menu lists accounts for which data is stored in the data store from which 
value may be transferred. After selecting a "transfer from" account, the personal ATM prompts 
the user to enter the amount of value to transfer with a "transfer amount" menu 934. Once the 
user has selected the accounts and the amount of value to transfer, the personal ATM is operative 
to use the host banking system service at the host ATM or an Internet service to send transaction 
messages for transferring value between the selected accounts. If the transaction succeeds or if 
there are errors, the personal ATM is operative to display appropriate additional menus 
prompting the user for additional information and/or instructions related to continuing or 
aborting the transaction. 

Figure 28 is representative of menu screens of the personal ATM for withdrawing cash. 
A personal ATM that is in operative connection with a host ATM with a cash dispenser is further 
operative to display a "withdrawal from account" menu 140 that lists a plurality of accounts 
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stored in the data store of the personal ATM for withdrawing money. Once a user selects the 
account, the personal ATM prompts the user to enter the amount of cash to dispense with the 
"withdrawal amount" menu 942. After the account and amount information has been entered, 
the personal ATM is operative to use the cash dispenser proxy methods to initiate the dispensing 
of cash from the selected account. The cash dispenser service is operative to validate the 
transaction, to debit or charge the amount of money from the selected account and to dispense the 
cash to the user. 

Figure 29 is representative of personal ATM interface menus for depositing value. When 
a personal ATM is in operative connection with a host ATM that includes a cash recycler, 
envelope or other deposit accepting service, the personal ATM is operative to display a "deposit 
to" menu 950. This menu lists a plurality of accounts stored in the data store of the personal 
ATM to which money may be deposited. After the user selects an account, the personal ATM is 
operative to display a "deposit from" menu 952 that includes a list of available depository 
services associated with the host ATM. After selecting the type of service to use, the personal 
ATM displays a "deposit amount" menu 954 that prompts the user for the amount of the cash, the 
value of a check or value of other item(s) that is being deposited with the deposit services of the 
host ATM. After entering this information, the personal ATM is operative to have the selected 
deposit service acquire the cash, envelope or other deposit item from the user and to credit the 
selected account. 

Figure 30 is representative of personal ATM menu screens for paying value. When a 
personal ATM is in operative connection with host POS service, the personal ATM is operative 
to display a "payment to" menu 960 with a list of all the POS services that the personal ATM has 

49 



access to. The user is prompted to select a POS service with which- to interface. After selecting a 
POS service or if there is only one POS service available, the personal ATM will only display the 
"payment from" menu 962, which prompts the user to select one of the accounts stored in the 
data store for paying for a purchase. After selecting the account, the personal ATM is operative 
to display a "payment validation" menu 964 with the amount of value that the POS service 
indicates is the payment amount. If the user confirms the payment, the personal ATM service is 
operative to invoke POS proxy methods to have the POS service initiate the payment from the 
selected account. 

Figure 3 1 is representative of personal ATM menus for dispensing items. When the 
personal ATM is in operative connection with a host dispenser, the personal ATM is further 
operative to display a "dispense" menu 970 with a list of available dispensers. Upon a user 
selecting one of these, the personal ATM service is operative to use the proxy to the host 
dispenser to display a dispenser interface 972 for interacting with the dispenser service. If the 
personal ATM includes its own display service and input service, the dispenser interface is 
displayed in the display service of the personal ATM. If the personal ATM resides on a smart 
card, the dispenser interface is displayed on the display device of the host dispenser and interacts 
with the smart card service through a personal ATM proxy. Once a user has finished selecting 
items to dispense, the dispenser service is operative to have the personal ATM display a 
"payment from" menu 974 with a list of accounts stored in the data store of the personal ATM 
for payment to the dispenser. Upon selecting one of the accounts, the personal ATM is operative 
to display a "validate payment" menu 976 which requests the user to verify that the amount of 
money the dispenser requires is correct. If the user verifies the amount, the personal ATM is 
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operative to invoke the dispense methods of the dispenser proxy to have the host dispenser debit 
the selected account and to dispense the selected item. 

Figure 32 is representative of the "edit account" menu 980 of the personal ATM. This 
menu includes a list of all the account information stored in the data store of the personal ATM. 
This account information includes the name of the account 982, the type of account 984, the 
password or pin number 986 of the account, the account number 988, the expiration date of the 
account 990, and the issuer ID or routing number 992 of the account. 

In addition to storing information that corresponds to standard banking and credit type 
accounts, embodiments of the personal ATM may also include local storage for data that is 
representative of value. The local storage may include information that is representative of 
points for purchasing food from a cafeteria, food stamps, electronic money or any other data that 
corresponds to value. For example, electronic money may include encrypted units of value that 
are stored locally and transferred to other individuals without debiting or crediting an external 
account or line of credit. 

The personal ATM of embodiments of the present invention offers the advantage of 
storing personal account information and stored value in one password protected and convenient 
location. Further, embodiments of the personal ATM may include their own interface 
application and uniform menus, so that a plurality of different types of transactions can be 
performed with the same familiar and easy to use personal interface. Services that do not exist 
locally are a simple and automatic connection away. Such connections to host services can be 
made by plugging the personal ATM into a universal network connection, or by a contact-less 
connection such as with an IR or RF interface. 
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Although previously described embodiments discuss the configuration and interaction 
between a plurality of services on a network, the present exemplary invention may also be 
applied to interactions between services that are performed off-line. For example, an alternative 
embodiment of the personal ATM could use a previously retrieved service proxy to prepare and 
simulate a series of transaction steps off-line prior to connecting to a host ATM. Such 
simulations may be performed with service proxies that are operative to behave as virtual 
services. A virtual service for a printer service for example, would respond programmatically 
just as an actual printer service, but without causing a hardware device to print on paper. Such 
simulated services in a personal ATM may be useful for testing complex transactions without 
actually transferring value. 

As an example, a personal ATM may be able to access a service for performing complex 
transactions such as stock market purchases. Such a stock trader service may require value from 
an account of the personal ATM to be transferred to an account associated with the stock trader 
service. If the transaction is complex, such as a reallocation of many stocks, the user may choose 
to assemble and test the transaction off-line using the virtual service features of the service proxy 
associated with the stock trader service. As part of the process for setting up the trade, the stock 
trader service proxy may prompt the personal ATM service to have the user select one of the 
accounts associated with the personal ATM to use for transferring value during the trade. When 
the user wishes to perform the transaction on-line, the stock trader service proxy can re-run or 
commit the transaction with the service proxy in communication with stock trader service. 

In other alterative embodiments of the present invention, services may be operative to 
perform transaction off-line as well. For example when a personal ATM is in communication 

52 



with a service such as the previously described stock trader service, the user may invoke a 
transaction of the stock trader service that is conditioned on certain events occurring in the 
future. After the personal ATM has disconnected from the network that includes the stock trader 
service, the conditional transaction will still be executed if the stock trader service determines 
that the specified conditions are satisfied. Such conditions could include the purchase of a stock 
if the price falls to a desired level for example. In this manner a service can act as virtual agent 
which performs transactions for the user when the communication between the personal ATM 
and the services has been severed. 

As discussed previously, the personal ATM may include a personal ATM service that can 
be accessed through a personal ATM proxy. In the previously described embodiments, methods 
of the personal ATM proxy are invoked by a host machine such as a host ATM to perform such 
actions as validating passwords and retrieving account information. However as a service, the 
personal ATM can be accessed by other applications as well, including applications that are 
resident on the same machine as the personal ATM. Such other applications may include 
accounting software, e-commerce applications, a web page for ordering items from an Internet 
merchant, or any other application that may require account information for performing 
transactions. 

As a service, the personal ATM may include public methods which allow other 
applications and other services to access information managed by the personal ATM. Such 
public personal ATM methods may include methods for retrieving an account to transfer value 
from or method for retrieving an account to transfer to value to. When such methods are called, 
the personal ATM service is operative to send a list of accounts to the calling application or 
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service. However, to keep personal account information secure, the public methods jof the 
personal ATM may require a personal ATM password or other validating data as an argument. If 
personal ATM methods are invoked with a validating argument that is null or incorrect, the 
personal ATM service may be further operative to prompt the user to enter the password before 
transferring any information to an external application. 

Any application that requires the transfer of value from an account may be configured to 
interface with the personal ATM using the previously described protocols for service to service 
communication. This enables the personal ATM to be used as a digital wallet for managing the 
transfer of value and for performing faster, more convenient, and more secure purchases with 
external services. 

v\ ^ ^huTTftrnyntcm qjirjmrfhod for connecting services to an ATM of the present invention 
achieves the above stated objectives, elimmafSs^if^culties encountered in the use of prior 
devices and systems, solves problems and attains the desirable^re^ults described herein. 

In the foregoing description certain terms have been used for brevity, clarity and v 
understanding, however no unnecessary limitations are to be implied therefrom because such 
terms are used for descriptive purposes and are intended to be broadly construed. Moreover, the 
descriptions and illustrations herein are by way of examples and the invention is not limited to 
the exact details shown and described. 

In the following claims any feature described as a means for performing a function shall 
be construed as encompassing any means known to those skilled in the art to be capable of 
performing the recited function, and shall not be limited to the structures shown herein or mere 
equivalents thereof 
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Having described the features, discoveries and principles of the invention, the manner in 
which it is constructed and operated, and the advantages and useful results attained; the new and 
useful structures, devices, elements, arrangements, parts, combinations, systems, equipment, 
operations, methods and relationships are set forth in the appended claims. 
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